The NFV initiative aims to create a unique network architectural framework for network function virtualization and, at same time, to keep same level of feature and telco grade as before and to align all the different telco, open source and IT initiatives to a clear defined set of logical function, interfaces and interworking procedures.
For the purpose of our invention we consider it as the reference cloud based network since the NFV architecture is supported by the majority of telco, IT big players and can be easily mapped to most of real cloud infrastructure and virtualized functions available today.
FIG. 1 is illustrating a Lawful Interception system connected to a cloud based network according to prior art.
The illustrated LI system 10 comprises a Law Enforcement Monitoring Facility (LEMF) 12, a LI external network 13, a physical LI site 14, a LI internal operator network 15 and means 16 for intercepting subscriber sessions and retrieving Communication Content and Intercepted Related Information of the intercepted sessions.
The IIF means 16 comprises an Internal Interception Function (IIF). Said IIF means 16 is located in nodes 20 of a telecommunications network.
The physical LI site 14 is also denoted Intercept Mediation and Delivery Unit (IMDU) and it comprises an Administration Function (ADMF) 18, an IRI Mediation Function (IRI MF) 24, a Delivery Function (DF2) 22, a CC Mediation Function (CC MF) 28 and a Delivery Function (DF3) 26. The LI external network 13 handles the standardized interfaces HI1, HI2 and HI3 between the physical LI site 14 and the LEMF 12. The LI internal operator network 15 handles the interfaces X1, X2 and X3 between the physical LI site 14 and the nodes 20 comprising IIF means 16.
An IIF realizes the interception of the communications to/from a provisioned subscriber, even denoted as a target. The administration function, ADMF, 18 provides the identity of the monitored subscriber according to a warrant emitted by local authorities via an X1 interface. For each intercepted session by a target, the IIF produces a sequence of Intercepted Related Information, IRI, containing the information about call participants, call progress and other relevant parameters. If required by a warrant, the IIF produces also a copy of the call content transmitted and received by the monitored subscriber. Call content is denoted Communication Content, CC, according to the LI standardization. The IIFs delivers IRI to a IRI mediation function via an X2 interface and Communications Content via an X3 interface.
The IRI Mediation Function (IRI MF) 24 validates, complements with other information, formats the received IRI in a standard format, called HI2, and delivers by means of the DF2 22 the IRI to the LEMF 12 via the HI2 handover interface.
The CC Mediation Function (CC MF) 28 is a corresponding functionality as the IRI MF, i.e. it validates, complements with other information, formats the received CC in a standard format, called HI3, and delivers by means of DF3 26 the CC to the LEMF 12 via an HI3 handover interface.
The LEMF 12 is the agency facility located outside the network operator where the intercepted IRI and CC is collected and finally used by local authorities for any legal and investigation purposes.
The NFV architecture captures and describe how a network function (NF) is created and managed in cloud environments to deal with the three following main differences respect to the native (non virtualized) deployment:                Decoupling software from hardware: a vendor will not provide any longer an integrated HW and SW network function. They could be provided by different vendors and evolve independently.        Flexible network function deployment: the decoupling of SW and HW open the possibility to share HW between different service hence to enable a faster and flexible creation of services as composition of SW application instances sharing the same physical platform. The flexibility represent a benefit but introduce also the need of a more advanced management able to compose service and manage them along their lifecycle.        Dynamic operation: the HW resources can be allocated on needed base with an optimal distribution among all the applications as well as the possibility to change the allocation to dynamically increase the performance of the application when at run time.        
The FIG. 1 contains the current reference architecture of NFV framework of a cloud based network as described in ETSI NFV specification.
The cloud based network 30 is composed by three main sub-domains:                The Virtualized Network Functions 34—VNF—as the software implementation of a network function which is capable of running over the NFVI.                    The domain contains both the network functions and its associated element management system—EMS 36—(i.e. the software responsible to local configure and maintain the network function parameters as local agent of the global OSS).            How these function get virtualized depends on the underlying NFVI e.g. the virtualization layer can provide a full virtual host fully simulating a real HW/SW host or virtualize only some OS functions while keep the rest native).                        The NFV infrastructure 31—NFVI—including the diversity of physical resources and how these can be virtualised. NFVI supports the execution of the VNFs.                    It comprises the actual HW computational, storage and network resources and the middleware virtualization SW creating logical partitions of them and providing an interface to enable VNFs to use them. Such interface is also called container.                        The NFV Management And Orchestration 37 and 38—MANO—which covers the orchestration and lifecycle management of physical and/or software resources that support the infrastructure virtualisation, and the lifecycle management of VNFs. NFV Management and Orchestration focuses on all virtualisation-specific management tasks necessary in the NFV framework.                    The management is achieved by the following management functions, one for each layer of the NFV. They are logically separated but this does not exclude they can be implemented in one SW module:                            The virtualised infrastructure management comprises the functionalities that are used to control and manage the interactions of a VNF with computing, storage and network resources under its authority, as well as their virtualisation.                A VNF Manager is responsible for VNF lifecycle management (e.g. instantiation, update, query, scaling, termination). Multiple VNF Managers may be deployed; a VNF Manager may be deployed for each VNF, or a VNF Manager may serve multiple VNFs.                The Orchestrator is in charge of the orchestration and management of NFV infrastructure and software resources, and realizing network services on NFVI. It acts as the main front end to a user of the cloud who intends to create, activate, terminate new services.                The OSS/BSS (Operation Support System/Business Support System) is in charge of configuring and administering the VNF similarly at what it does for non-virtualized network function. The OSS/BSS is not charge and not allowed to configure LI functions.                                    A network service is defined as a set of VNFs, network connections between them and a deployment template, is provisioned by an orchestrator user and stored in the orchestrator DB called catalog.                                                                                
The data-set “Service, VNF and Infrastructure Description” is a complementary context specific additional info. This data-set provides information regarding the VNF deployment template, VNF Forwarding Graph (i.e. network connection graph), service-related information, and NFV infrastructure information models.
The interception access point (IAP), also named internal interception function (IIF) can be embedded in a network function or be a separate network function itself (e.g. a passive LI probe system). As for other network function, the decoupling of HW/SW in NFV lead also to a split of IIF in multiple interception points distributed in all NFV layers, independent each other, potentially provided by different vendors and owned by different stakeholders.
In particular a IIF getting virtualized can be split in:                A virtual IIF function along the VNF is which is embedded (35) e.g. in a virtual CSCF or SBG or a VNF itself if the IIF is a separate application (35) e.g. a virtual passive LI probe.                    In the latter case an associate virtual EMS could be not present or be replaced by virtual probe management agent.                        An IIF as interception function provided by the virtualization middleware for each VNF to which it provides a container (33) e.g. a function able to sniff all the disk I/O or network traffic.        An IIF as an HW probe system (32) which analyses all the IP traffic in HW network and extract traffic relevant for a specific monitored user and protocol.        
The other figure, FIG. 2, illustrates and describes more in detail the split of a IIF embedded in a VNF. According to ETSI NFV GS MAN001 a network function when virtualized is decoupled in an host function i.e. a logical partition of HW resources, a container i.e. a virtual machine which can host a VNF, and a virtual application i.e. the VNF.
Similarly any interface as well as IIF interfaces of the original network function get split in two interfaces: one HW network interface on which real traffic will flow through and one virtual which will represent a virtual channel made available from HW network interface to the VNF by the virtualization layer.
In addition for a LI there are also other two interfaces: the container side channel exposed by the IIF described in 33 and HW side channel exposed by the IIF described in 32. The main effects of the migration is that the number of interception points, aka IIF, increases significantly, are distributed in a large network cloud system or even on more than one and can be used independently or in combination to realize a LI service. This situation from one view point increases the flexibility of the LI solution but from another side it increases the possibility to abuse of it. Furthermore a LI function has a cost in terms of resources and impact of normal traffic function, both should be minimized.